REMARKS 

The Office Action dated July 1 1, 2008 has been received and carefully noted. The 
above amendments to the claims, and the following remarks, are submitted as a full and 
complete response thereto. 

By this Response, claims 1, 6 and 10-13 have been amended to more particularly 
point out and distinctly claim the subject matter of the present invention. No new matter 
has been added. Accordingly, claims 1-13 are currently pending in the application, of 
which claims 1, 6 and 10 are independent claims. 

In view of the above amendments and the following remarks, Applicant 
respectfully requests reconsideration and timely withdrawal of the pending rejections to 
the claims for the reasons discussed below. 

The Office Action objected to claims 1, 6, and 10-13 because of minor 
informalities. Applicants have amended claims 1, 6 and 10-13 to recite "a plurality of 
other cells." Withdrawal of these objections is kindly requested. 

The Office Action rejected claims 1-13 under 35 U.S.C. §112, second paragraph, 
as allegedly being indefinite for failing to particularly point out and distinctly claim the 
subject matter which Applicant regards as the invention. Specifically, the Office Action 
alleged that it is not clear what is meant by "cell" as it is recited in the claims and with 
respect to the disclosure of the specification. Applicant respectfully traverses this 
rejection for at least the following reasons. 
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Claim 1 recites "a data packet comprising a plurality of cells." In other words, the 
plurality of cells represent portions of the packet which make up the contents of the data 
packet. As paragraph [0005] of the present application indicates, a "cell" is quite simply 
a fixed-length amount of data - meaning the amount of bits that may be included in a 
particular cell are consistent. A packet is different in that it may be larger or smaller 
depending on the amount of data it carries in transport. Applicant submits that there is 
nothing that renders the scope of the claim "ascertainable" (as noted in the Office Action) 
simply because "cells" are recited in the pending claims as being part of a data packet. 
Furthermore, there is no need to identify the specific type of packet (e.g., Ethernet, IP or 
an ATM cell) which may be implemented by the subject matter of the claims. 
Withdrawal of the rejection is kindly requested. 

The Office Action rejected claims 1-4, 6-8, and 10-12 under 35 U.S.C. § 103(a) as 
being allegedly unpatentable as obvious over Thompson (European Publication No. 
EP 0572145 A2) ("Thompson") in view of Scott (U.S. Patent No. 6,512,773) ("Scott"), 
and further in view of Parruck, et al (U.S. Patent No. 7,139,271) ("Parruck"). According 
to the Office Action, Thompson teaches all of the elements of claims 1-4, 6-8 and 10-12 
except for a data packet including a plurality of cells including a header cell, wherein the 
header cell of the plurality of cells includes a header and a packet data portion and a 
counter to determine the number of bytes of a packet after the header has been removed. 
Thus, the Office Action uses Scott and Parruck to cure the deficiencies of Thompson in 
an effort to yield the combination of elements recited in claims 1-4, 6-8 and 10-12. The 
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rejection is traversed as being based on references that neither teach nor suggest the novel 
combination of features clearly recited in claims 1-4, 6-8 and 10-12. 

Claim 1, upon which claims 2-5 depend, recites a network device that is 
configured to prevent data misalignment of a data packet containing extra header bytes. 
The network device includes an ingress module having an input interface to receive a 
data packet including a plurality of cells. A header cell of the data packet is one of the 
plurality of cells of the data packet. The header cell of the plurality of cells includes a 
header and packet data information. The header cell includes the header in its entirety 
for the data packet. The device also includes a header detector configured to detect the 
header cell of the data packet and remove the header from the header cell of the data 
packet. The network device also includes a counter configured to determine whether the 
header cell of the data packet contains a multiple of a predetermined number of bytes 
after the header has been removed from the header cell. The network device further 
includes an insertion module configured to insert null bytes into the header cell of the 
data packet to form a modified header cell of the data packet if the counter determines 
that the header cell of the data packet does not satisfy the multiple of the predetermined 
number of bytes in order to align all of a plurality of other cells of the packet. The 
network device also includes an extraction module configured to remove the null bytes 
from the modified header cell of the data packet as a modified cell of the data packet 
exits the network device. 
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Claim 6, upon which claims 7-9 depend, recites a method of preventing data 
misalignment of a data packet containing extra header bytes. The method includes 
receiving, at an input port of a network device, a data packet including a plurality of cells. 
A header cell of the data packet is one of the plurality of cells of the data packet. The 
header cell of the plurality of cells includes a header and packet data information. The 
header cell includes the header in its entirety for the data packet. The method also 
includes detecting the header cell of the data packet, removing the header from the header 
cell of the data packet and determining whether the header cell of the data packet 
contains a multiple of a predetermined number of bytes after the header has been 
removed from the header cell. The method further includes inserting null bytes into the 
header cell of the data packet to form a modified header cell of the data packet if the 
counter determines that the header cell of the data packet does not satisfy the multiple of 
the predetermined number of bytes in order to align all of a plurality of other cells of the 
packet and forwarding the modified cell of the data packet to an output port. The method 
also includes removing the null bytes from the modified header cell of the data packet as 
a modified cell of the data packet exits the network device. 

Claim 10, upon which claims 11-13 depend, recites a network device configured 
to prevent data misalignment of a data packet containing extra header bytes. The 
network device includes receiving means for receiving, at an input port of a network 
device, a data packet including a plurality of cells. A header cell of the data packet is one 
of the plurality of cells of the data packet. The header cell of the plurality of cells 
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includes a header and packet data information. The header cell includes the header in its 
entirety for the data packet. The network device also includes detecting means for 
detecting the header cell of the data packet. The network device also includes header 
removing means for removing the header from the header cell of the data packet and 
determining means for determining whether the header cell of the data packet contains a 
multiple of a predetermined number of bytes after the header has been removed from the 
header cell. The network device further includes inserting means for inserting null bytes 
into the header cell packet to form a modified header cell of the data packet if the counter 
determines that the cell of the data packet does not satisfy the multiple of the 
predetermined number of bytes in order to align all of a plurality of other cells of the 
packet and forwarding means for forwarding the modified cell of the data packet to an 
output port. The network device also include null byte removing means for removing the 
null bytes from the modified header cell of the data packet as a modified cell of the data 
packet exits the network device. 

Initially, Applicant notes that page 13 of the Office Action mailed on July 11, 
2008 admitted that Thompson fails to disclose or suggest "a counter configured to 
determine whether the header cell of the data packet contains a multiple of a 
predetermined number of bytes after the header has been removed from the header cell 55 , 
as recited, in part, in independent claim 1 and similarly in independent claims 6 and 10. 
Applicants agree that Thompson fails to disclose the above-noted claim features of claims 
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1, 6 and 10. However, Applicants disagree that Scott cures those deficiencies of 
Thompson. 

Claim 1 recites, in part, "a counter configured to determine whether the header cell 
of the data packet contains a multiple of a predetermined number of bytes after the header 
has been removed from the header cell." Similar claim recitations are also recited in 
independent claims 6 and 10. The Office Action relied on column 10, lines 40-50 and 
FIG. 5 of Scott as allegedly disclosing this feature of the claims. Applicant disagrees that 
Scott discloses determining whether the header cell of a data packet contains a multiple 
of a predetermined number of bytes after the header has been removed from the header 
cell. 

Column 10, lines 40-50 of Scott discloses 

"In block 231, the payload (105a of FIG. 4A) is processed 
from the frame 100. The number of octets of the user data 
PDU 71 of the payload is counted in block 232. This value 
forms the length field of the AAL5 CS. Note that the user 
data PDU 71 is the field found after the 4-octet ATM 
header field 91 of FIG. 4A . Block 234 forms the UU and 
CPI fields of the AAL5 frame. For the case where the UU and 
CPI field are not included in the header or trailer, the default 
"0" is used. Block 236 adds pad characters to make the AAL5 
frame equal an integer number of 48 octet cells. In block 237, 
the 32 bit cyclic redundancy check (CRC) of the AAL5 frame 
is calculated. Block 238 segments the above AAL5 frame into 
an integer number of 48 octet cells." 

As can be clearly observed from column 10, lines 40-50 of Scott the only part of the 

frame 100 that is "counted" is the "User Data PDU" (i.e,. 71) portion of the Payload 

105a. In other words, the "4 octet ATM header" (i.e., 91) is not part of the counting 
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operation performed by Scott. The only counting performed in Scott is counting on the 
number of octets of the user data included in the payload 71. The number of octets is 
used for the length field of the ATM adaptation layer-5 convergence sub-layer (AAL5 
CS). The counting of the data octets in the payload is again reinforced in operation 232 
of FIG. 5C. Once the segmentation of the 48 octet cells of data are prepared, then the 4 
octet ATM header is extracted from the frame and HEC is added to create the 5 octet 
ATM header. The 5 octet ATM header is then combined with the 48 octet payload to 
create a conventional 53 octet ATM cell. 

Scott does not disclose using a counter to determine whether the header cell of 
the data packet contains a multiple of a predetermined number of bytes after the header 
has been removed from the header cell. The only operations that Scott performs after the 
header is extracted in operation 239 of FIG. 5C is adding the HEC to the header, adding 
the header back to the 48 octet payload, and appending a "last cell indicator" for the last 
cell (see operations 239-244 of FIG. 5C). Therefore, Scott does not disclose or suggest 
"a counter configured to determine whether the header cell of the data packet contains a 
multiple of a predetermined number of bytes after the header has been removed from the 
header cell", as recited, in part, in independent claim 1 and similarly in independent 
claims 6 and 10. Furthermore, Parruck also fails to cure the deficiencies of Thompson 
and Scott with respect to the pending claims. 

Parruck discloses that a large ATM cell is divided into individual cells, each of the 
individual cells include a header and a payload portion. Each data packet is divided into 
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multiple header cells because each cell includes header and payload portions. There is no 
disclosure or suggestion in Parruck of "a counter configured to determine whether the 
header cell of the data packet contains a multiple of a predetermined number of bytes 
after the header has been removed from the header cell", as recited, in part, in 
independent claim 1 and similarly in independent claims 6 and 10. 

Therefore, Applicants respectfully assert that the rejection under 35 U.S.C. 
§ 103(a) should be withdrawn because neither Thompson, Scott nor Parruck, whether 
taken singly or combined, teaches or suggests each feature of claims 1, 6 and 10. Each of 
claims 2-4, 7-8 and 11-12 depend on claims 1, 6 and 10 and should be allowed at least 
because of their dependence on claims 1, 6 and 10, in addition to the further limitations 
recited in claims 2-4, 7-8 and 11-12. The failure to teach each of the claim recitations of 
the pending claims demonstrates that a prima facie case of obviousness has not been 
established. Withdrawal of the rejections of claims 1-4, 6-8 and 10-12 is kindly 
requested. 

Claims 5, 9 and 13 were rejected under 35 U.S.C. 103(a) as being obvious over 
Thompson in view of Scott and further in view of Parruck and U.S. Patent No. 6,697,873 
Bl to Yik. According to the Office Action, Thompson, Scott and Parruck teach all of the 
elements of claims 5, 9 and 13 except for teaching that the medium access control 
protocol module has a MAC address for transmitting the modified cell of the data packet 
and a layer two switching module configured to build a table for forwarding rules upon 
which the MAC address exists. Therefore, the Office Action combined the teachings of 
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Yik with Thompson, Scott and Parruck to allegedly yield all of the elements of claims 5, 
9 and 13. The rejection is traversed as being based on references that neither teach nor 
suggest the novel combination of features clearly recited in independent claims 1, 6 and 
10, upon which claims 5, 9 and 13 depend. 

Yik also does not cure the deficiencies of Thompson, Scott and/or Parruck, as 
outlined above. Yik teaches an apparatus and method for storing and searching computer 
node addresses in a computer network system. Each of claims 5, 9 and 13 depend on 
claims 1, 6 and 10 respectively, and thus, incorporates all of the elements of the 
independent claims. 

There is no teaching or suggestion in Yik of "a counter configured to determine 
whether the header cell of the data packet contains a multiple of a predetermined number 
of bytes after the header has been removed from the header cell", as recited, in part, in 
independent claim 1 and similarly in independent claims 6 and 10, upon which claims 5, 
9 and 13 depend. Therefore, Applicants respectfully assert that the rejection under 35 
U.S.C. § 103(a) should be withdrawn because neither Thompson, Scott, Parruck nor Yik, 
whether taken singly or combined, teaches or suggests each feature of claims 1, 6 and 10. 
Each of claims 5, 9 and 13 depend on claims 1, 6 and 10 and should be allowed at least 
because of their dependence on claims 1, 6 and 10, in addition to the further limitations 
recited in claims 5, 9 and 13. 

As noted previously, claims 1-13 recite subject matter which is neither disclosed 
nor suggested in the prior art references cited in the Office Action. It is therefore 

- 16 - Application No.: 09/982,794 



respectfully requested that all of claims 1-13 be allowed, and this application passed to 



If for any reason the Examiner determines that the application is not now in 
condition for allowance, it is respectfully requested that the Examiner contact, by 
telephone, the applicant's undersigned representative at the indicated telephone number 
to arrange for an interview to expedite the disposition of this application. 

In the event this paper is not being timely filed, the applicant respectfully petitions 
for an appropriate extension of time. Any fees for such an extension together with any 
additional fees may be charged to Counsel's Deposit Account 50-2222. 
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